[% setvar title The Perl 6 Summary for the fortnight ending 20040621 %]
<div id="archive-notice">
    <h3>This file is part of the Perl 6 Archive</h3>
    <p>To see what is currently happening visit <a href="http://www.perl6.org/">http://www.perl6.org/</a></p>
</div>
<div class='pod'>
<a name='The Perl 6 Summary for the fortnight ending 20040621'></a><h1>The Perl 6 Summary for the fortnight ending 20040621</h1>
<p>Good evening. You find me typing away in a motel room on the edge of the
Lake District on the shortest night of the year. I suppose, by rites, I
should be spending the night by some stone circle drinking, dancing and
generally making merry, but as I'm a teetotal, unfit, atheistical nerd
with a mission to summarize I'll skip that and plough straight into the
activities of another arcane sect. Yes, it's perl6-internals again...</p>
<a name='Towards an accurate README'></a><h2>Towards an accurate README</h2>
<p>Andy Dougherty sent in a patch adjusting the Parrot README so that it
accurately reflected the toolset needed to build parrot. For some
reason, as well as the requirement for a C++ compiler if you want to
build the ICU library, we've moved to needing Perl 5.6.0 rather than
5.005. Nicholas Clark suggested that, rather than bumping the Perl
version requirement, we bundle appropriate versions of modules Parrot
required, but chromatic thought it better to check the for the correct
versions of said modules at Configure time and bail out if they weren't
there.</p>
<p>There was further discussion about whether going to Perl 5.6.0 as a
requirement was the right thing to do -- the issue is that some OSes
(FreeBSD and Solaris 8 were cited) still only ship with 5.005 family
Perls. My feeling (which I didn't mention in the thread, more fool me)
is that, as eventually the goal is to eliminate the need for Perl at
all in the build process, then require 5.6.0 rather than 5.005 isn't
exactly the end of the world.</p>
<p><a href='http://groups.google.com/groups?selm=rt-3.0.9-30095-89885.16.61061401395@perl.org' target='_blank'>groups.google.com</a></p>
<p><a href='http://groups.google.com/groups?selm=Pine.SOL.4.58.0406091317550.12666@maxwell.phys.lafayette.edu' target='_blank'>groups.google.com</a></p>
<a name='OS X Builds again'></a><h2>OS X Builds again</h2>
<p>Someone finally summoned up the tuits to fix the OS X build. Step
forward Nicholas Clark and accept your plaudits.</p>
<p><a href='http://groups.google.com/groups?selm=a06110404bcee2724f70a@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Basics of the PMC class set'></a><h2>Basics of the PMC class set</h2>
<p>Dan announced that he was about to make some changes to the repository,
including establishing a basic set of PMC classes. Matt Fowles wondered
about Array PMCs, which seemed to be missing from Dan's list. Dan
agreed that they should be rationalized as well.</p>
<p>Bernhard Schmalhofer suggested adding a complex number class to Dan's
basic menagerie, but Dan was unconvinced.</p>
<p><a href='http://groups.google.com/groups?selm=a06110402bcee766bc83c@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Correct use of #define'></a><h2>Correct use of #define</h2>
<p>Nicholas Clark was moved to growl by a section of
<b><i>include/parrot/string.h</i></b> that used a #define to define a
type. Actually, he was moved to 'swearing and cursing and time wasted
grepping to find out what a STRING is'. Dan agreed that this was bad
and decreed: 'Typedefs for types, #defines for constants and bizarre
(<i>temporary!</i>) debugging things.'</p>
<p><a href='http://groups.google.com/groups?selm=20040611095043.GB81272@plum.flirble.org' target='_blank'>groups.google.com</a></p>
<a name='The next release'></a><h2>The next release</h2>
<p>During a lull while Leo TÃ¶tsch was away at a conference, Dan mused on
the next release of parrot. His goal for that is a rejig of
<b><i>classes/</i></b>, aiming to make sure that all the PMCs we want are in and
working, and that the ones we don't care about are neatly deprecated.</p>
<p>Warnock applies.</p>
<p><a href='http://groups.google.com/groups?selm=a06110409bcefa5f8c6ff@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='A small task for the interested'></a><h2>A small task for the interested</h2>
<p>Stretching the definition of 'small' somewhat, Dan asked for volunteers
to implement the missing PMCs detailed in PDD 17. He reckoned it should
be 'fairly straightforward'. A new entrant in these summaries, Ion
Alexandru Morega took a crack at the String PMC and posted a patch to
the list which was promptly ignored. Which seems a little unfair really.</p>
<p><a href='http://groups.google.com/groups?selm=a0611040abcefb912413e@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Bignums!'></a><h2>Bignums!</h2>
<p>Dan asked for a volunteer to get Bignums working. Alin Iacob stepped up
to the plate. Leo suggested that, rather than starting from
<b><i>types/bignum.c</i></b>, it might be better to use an existing, maintained,
maths (Look, I'll spell 'summarise' with a 'z' -- the OED does -- but
it will be a cold, cold day in hell when I start abbreviating
'mathematics' as 'math'. Ahem.) package. Dan worried about license
compatibility; the proposed GMP package is licensed under the LGPL
which may (or may not) be compatible with Parrots Artistic/GPL dual
licence. After a closer reading he reckoned that GMP's license is
definitely incompatible with Parrot.</p>
<p><a href='http://groups.google.com/groups?selm=a0611040bbcefb9fb77e6@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Adding Fixed*Array classes'></a><h2>Adding Fixed*Array classes</h2>
<p>Matt Fowles posted a patch implementing Fixed Array classes. Dan
applied it. Leo wondered about the patch's use of malloc(3) instead of
Parrot's memory management. Dan wasn't worried in the case of fixed
size arrays.</p>
<p><a href='http://groups.google.com/groups?selm=rt-3.0.9-30230-90377.3.32088317231715@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Resizeable*Array classes'></a><h2>Resizeable*Array classes</h2>
<p>Fresh from his Fixed Array triumph, Matt Fowles posted a patch
implementing naÃ¯ve Resizeable Arrays. Leo thought it a little too
naÃ¯ve, and worried about duplication of existing functionality. Dan
wasn't worried about the naÃ¯vetÃ©, or the duplication of functionality. He
pointed out that it was more important to get <i>something</i> which could
be improved and that the duplication was okay given that the idea was
to get a standard framework in place and then eliminate the
duplication. (I admit that I'm a little surprised to hear Dan, who's
normally a strong advocate of up front design, preaching the
refactorers creed...)</p>
<p><a href='http://groups.google.com/groups?selm=rt-3.0.9-30245-90438.1.98115444593533@perl.org' target='_blank'>groups.google.com</a></p>
<a name='Making PMCs'></a><h2>Making PMCs</h2>
<p>Nicholas Clark wondered how to go about making a PMC, pointing out that
the documentation is rather sparse. He had a bunch of questions for
the Men Who Know. Matt Fowles and Dan Sugalski came up with
answers. Leo wrote a document and checked it in as <b><i>docs/pmc.pod</i></b>. If
you're interested in implementing a PMC, you'd do well to read it.</p>
<p><a href='http://groups.google.com/groups?selm=20040613100125.GG81272@plum.flirble.org' target='_blank'>groups.google.com</a></p>
<a name='Slices and iterators'></a><h2>Slices and iterators</h2>
<p>Continuing his campaign to spec out more and more of Parrot, Dan set to
work on defining and documenting Parrot's handling of slices and
iterators. It appears that array slicing syntax is one of those topics
where you can't please everyone; Dan's post generated a good deal of
discussion.</p>
<p>Dan added more in a later post and, in later post still, threw up his hands and
asked for a volunteer to define the iterator protocol.</p>
<p><a href='http://groups.google.com/groups?selm=a06110409bcf382d914cc@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<p><a href='http://groups.google.com/groups?selm=a06110409bcf4cf7b179c@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<p><a href='http://groups.google.com/groups?selm=a0611040bbcf4ecb9f27f@' target='_blank'>groups.google.com</a>[172.24.18.98]</p>
<a name='Iterator semantics'></a><h2>Iterator semantics</h2>
<p>Having a syntax is all very well, but you need to define what it
<i>means</i> too. So Dan did.</p>
<p><a href='http://groups.google.com/groups?selm=a0611040abcf38b01fe20@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Some rationale for Parrot's mixed encoding scheme'></a><h2>Some rationale for Parrot's mixed encoding scheme</h2>
<p>Argh! Unicode! Run away!</p>
<p>Dan posted the rationale for his design for Parrot's strings, in
particular the decision to defer conversion of strings to
Unicode. Amazingly, there was no argument.</p>
<p><a href='http://groups.google.com/groups?selm=a0611041bbcf3f6bd3ee8@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Strings. Finally.'></a><h2>Strings. Finally.</h2>
<p>Dan posted &quot;the official, 1.0, final version&quot; of the Parrot Strings
document. Modulo a caveat about the use of 'grapheme' it looks like
this one might stick.</p>
<p><a href='http://groups.google.com/groups?selm=a06110418bcf3bff76821@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Strings internals'></a><h2>Strings internals</h2>
<p>Having got a Strings spec that people seemed to agree on, Dan went on
to discuss how parrot's strings should work internally. He and Mark A
Biggar ironed out a few wrinkles.</p>
<p><a href='http://groups.google.com/groups?selm=a06110403bcf61a2185f0@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Fixing pbc2c.pl'></a><h2>Fixing pbc2c.pl</h2>
<p>Dan asked for volunteers to get <b><i>build_tools/pbc2c.pl</i></b> working and/or
write a test suite for it.</p>
<p><a href='http://groups.google.com/groups?selm=a06110402bcf79fccdc91@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='PIO_unix_pipe'></a><h2>PIO_unix_pipe</h2>
<p>Leo's extended Parrot's <code>open</code> opcode to allow for opening a unix pipe
rather than simply a file. There were issues with passing arguments to
the the program being piped to/from, but Dan came up with a suggested
<code>backtick</code> opcode whose semantics were liked, but whose necessity and
name were called into question. Leo pointed out that the major credit
for the functionality belongs to Melvin Smith; Leo merely implemented a
means to get at the functionality from parrot code.</p>
<p><a href='http://groups.google.com/groups?selm=200406071207.i57C7bh27980@thu8.leo.home' target='_blank'>groups.google.com</a></p>
<a name='Teapots!'></a><h2>Teapots!</h2>
<p>Nick Glencross wants us all to look at his shiny SDL teapots; the poor
man's wife is apparently underwhelmed, so let's all make with the
&quot;Wooo! Well done that man!&quot;.</p>
<a name='Simple trinary ops'></a><h2>Simple trinary ops</h2>
<p>Dan toyed with adding a couple of non-flowcontrol min/max ops along the
lines of</p>
<pre>    min $P1, $P2, $P2 # Sets $P1 to the lesser of $P2 and $P3</pre>
<p>he noted that such ops would make some of the code he was generating
much simpler, but wasn't sure if that particular itch needed to be
scratched with a new op. He was rapidly convinced that it wasn't a good
idea (I wouldn't be surprised to discover that he was convinced of this
about 10 seconds after he hit the 'send' button for the thread's root
message).</p>
<p>Steve Fink attempted to resurrect the idea by proposing a single
<code>choose</code> operator, which looks rather neat, but is probably still
unnecessary.</p>
<p><a href='http://groups.google.com/groups?selm=a06110404bcf6254d244e@' target='_blank'>groups.google.com</a>[10.0.1.3]</p>
<a name='Meanwhile, in perl6-language'></a><h1>Meanwhile, in perl6-language</h1>
<a name='Cawley's Corollary to Godwin's Law'></a><h2>Cawley's Corollary to Godwin's Law</h2>
<p>Given enough time, any thread on perl6-language will end up arguing
the toss about Unicode operators.</p>
<p>Perl 6 will have Unicode operators. It will also have ASCII
equivalents. You're highly unlikely to convince Larry to change his
mind on this.</p>
<a name='IDs of subroutine wrappers should be objects'></a><h2>IDs of subroutine wrappers should be objects</h2>
<p>Ingo Blechschmidt made a convincing argument for making the subroutine
wrappers discussed in Apocalypse 6 into first class objects. (Well, I
was convinced.)</p>
<p>Later in the thread, Dan invoked &quot;our Quantum Ninjas&quot;.</p>
<p><a href='http://groups.google.com/groups?selm=20040608130813.23788.qmail@onion.perl.org' target='_blank'>groups.google.com</a></p>
<a name='Simple grammar example'></a><h2>Simple grammar example</h2>
<p>Aldo Calpini asked for assistance in coming up with a simple, yet
impressive, example of Perl 6 grammars. I'm not sure anyone's come up
with a suitably satisfactory example yet, but Garrett Goebel pointed
out that Damian has released Perl6::Rules. And there was much rejoicing
(well, in this summarizer's head there was).</p>
<p><a href='http://groups.google.com/groups?selm=40C71BFD.1050105@perl.it' target='_blank'>groups.google.com</a></p>
<p><a href='http://search.cpan.org/~dconway/Perl6-Rules-0.03/Rules.pm' target='_blank'>search.cpan.org</a></p>
<a name='Messages are not guaranteed to arrive in the order sent'></a><h2>Messages are not guaranteed to arrive in the order sent</h2>
<p>In a message dated 28th of January 2004, Damian Conway addressed the
issue of junctive lvalues.</p>
<p><a href='http://groups.google.com/groups?selm=40171197.6070401@conway.org' target='_blank'>groups.google.com</a></p>
<a name='Apologies, Acknowledgements, Announcements'></a><h1>Apologies, Acknowledgements, Announcements</h1>
<p>This summary would have been a great deal trickier to write it if
weren't for the efforts of Jeffrey Dik, Sebastian Riedel, Brent
Royal-Gorden and Robert Spier, all of whom helped me fill in my message
archive while my main server is away being fettled.</p>
<p>Apologies for the long URLs to those of you reading this in email; my
link shortening script is on the hard disk that's at the menders...</p>
<p>Computer menders and British Telecom willing, next week's summary will
actually happen. If it doesn't, I'll be along in a fortnight.</p>
<p>If you find these summaries useful or enjoyable, you can show your
appreciation by contributing to the Perl Foundataion to help support
the ongoing development of Perl. Money and time are both
appreciated. Or you could drop me a line at
mailto:<a href='mailto:p6summarizer@bofh.org.uk'>p6summarizer@bofh.org.uk</a>; I'm always happy to get feedback.</p>
<p><a href='http://donate.perlfoundation.org/' target='_blank'>donate.perlfoundation.org</a> -- The Perl Foundation</p>
</div>
